A memory controller manages the flow of data between a processor and a one or more memory modules on an interface or bus. The memory controller contains the logic needed to read and write to a memory module and refresh the data stored in the memory device. The memory module may comprise a dynamic random access memory (DRAM) made up of a plurality of DRAM ranks A memory rank is a set of memory devices, i.e., dies, in the memory module connected to the same chip select, and which are therefore accessed simultaneously, and which may share all of the other command and control signals, wherein only the data pins for each DRAM module are separate. The memory controller supports a protocol used by multiple memory modules coupled to the channel, such as the Joint Electron Device Engineering Council (JEDEC) Double Data Rate Third Generation (DDR3) Synchronous Dynamic Random Access Memory (SDRAM) protocol.
As DRAM devices become faster and denser, they consume more energy, even when the memory system is not servicing any requests. The increase in device speed leads to higher background power dissipation by the peripheral circuitry, and the increase in device density results in higher refresh energy. For instance, it is projected that refresh operations utilize a substantial amount of DRAM power while simultaneously degrading DRAM throughput in future 64 Gb devices. These trends have caused the memory subsystem to become a major contributor of energy consumption in current and future computing platforms.
Commodity DRAM devices employ low power operating modes to reduce the background power consumed by the peripheral circuitry. Current DRAM devices have the following three operational modes: (1) Active, (2) Power-Down (PD), and (3) Self-refresh (SR). Active mode is the normal operating mode in which the rank can immediately service requests. In the PD mode, some Input/Output (I/O) signals and peripheral logic are disabled, resulting in lower power consumption.
In SR mode, the entire DRAM clocked circuitry and the delayed lock loop (DLL) are turned off. Therefore, no power is consumed except by refresh operations, which are triggered internally in the DRAM by a built-in timer. The DDR3 switching time from SR to active mode is specified as the maximum of the following two parameters: (i) tRFC: the time required to service a refresh command, (ii) tDLLK: the DLL lock period. The tRFC increases with the size of the DRAM device, whereas tDLLK remains constant (e.g. 512 clock cycles in DDR3 devices) irrespective of device size and speed.
In DDR devices, scheduling of refresh operations is dictated by two timing parameters. The first parameter, tRFC, represents the time required to complete one refresh operation, and the second parameter, tREFI, specifies the average time period between two refresh operations. The value of tRFC depends upon the number of rows refreshed with one refresh operation, whereas tREFI depends on tRFC and the total number of rows to be refreshed. As device density increases, we either have to refresh more rows per refresh operation (increase tRFC) or service refreshes more frequently (decrease tREFI). DDR3 devices are specified to keep tREFI constant at 7.8 μs. Consequently, tRFC increases with increasing device density.
When the memory controller issues a refresh command (also called Auto-refresh) to a memory rank, each memory module in that rank simultaneously starts to refresh. Therefore the entire rank becomes unavailable to service any memory requests for tRFC period. Furthermore, auto-refresh commands can only be issued when the rank is in active mode. If the rank happens to be in PD mode, the memory controller must first transition it to the active mode, and then schedule an auto-refresh command. Consequently, while servicing auto-refreshes, DRAM devices not only consume refresh power but also high background power.
The most prevalent refresh approach in current-day memory controllers is Demand Refresh (DR), in which an auto-refresh command is issued immediately after every tREFI time period. However, DR does not address the increasing refresh penalty in high density devices. Recently proposed Elastic Refresh postpones up to eight refresh commands during a high memory activity phase, and then compensates by servicing those pending refreshes during a subsequent idle memory phase. To satisfy the average refresh rate constraint specified by tREFI, pending refreshes have to be issued at a rate faster than 1/tREFI. The Elastic Refresh memory controller satisfies this constraint by adjusting the auto-refresh command issue rate based on the number of pending refreshes. If the number of pending refreshes is high, auto-refresh commands are issued at a faster rate, and vice versa. Therefore, by scheduling most of the refreshes during idle periods, Elastic Replenish can mitigate the performance impact of refreshes.